Enhanced Communication Protocol for Iso/ieee 11073-20601

Syntax Notation One (ASN.1) [3] was chosen for representing all data types and exchange formats defined in OEP. ASN.1 is a standard notation used for describing rules and structures for information data. Many communication protocols specifications define messages as binary values of sequences of octets. ASN.1 provides means of defining complex data types and messages without necessarily determining their binary representation. This notation is supplemented by the specification of one or more algorithms called encoding rules, which determine the value of the octets that carry the application semantics (called the transfer syntax). ISO/IEEE 11073-20101:2004 [4] defines the medical device encoding rules (MDER) used in this standard. 10 Al. Egner, Florica Moldoveanu, Nicolae Goga, A. Moldoveanu, V. Asavei, Anca Morar 3. Enhancing communication in ISO/IEEE 11073-20601 The current version of OEP does not support authentication. OEP passes the security responsibility to the implementer. However, different implementations of authentication procedures lead to incompatibilities and interoperability problems. In the authors’ opinion, authentication guidelines should be at least provided, if not included in standard. The authors’ recent research [5] focused on designing an authentication procedure based on biometric keys, which can be integrated in an identity management system. The authentication is derived from the mutual challengeresponse [6] authentication protocol. The exchanged authentication information is contained in the association messages, stored in an optional field named optionList. The proposed authentication is designed to be optional, to maintain backward compatibility with existing implementations of OEP. Thereby, two different scenarios can be distinguished, in terms of the bidirectional association initiation: ‐ Extending the association procedure for implementations that allow the authentication procedure ‐ Extending the association procedure for implementations that do not allow authentication (existing implementations of the ISO/IEEE version of the protocol) 3.1. Bidirectional association when authentication is required This section proposes the extension of the association procedure for systems that employ authentication mechanisms. The method of authentication regarded here is the one considered in the recent research [5], i.e. mutual challenge-response. Fig. 3.1 describes the flow of messages exchanged between the Agent and the Manager when the Manager initiates the association procedure. Enhanced communication protocol for ISO/IEEE 11073-20601 11 Fig. 3.1. The message flow of an association procedure initiated by the Manager The Manager initiates communication by triggering the Agent to request for association. The first message in Fig. 3.1 represents the trigger message. Existing association message types were used for describing the exchange of authentication information. In this case, however, existing association message types cannot be used to trigger the association. These types can only be used when the Agent and the Manager are in the Associating state. Since the Manager is in the Unassociated state when initiating the association, new type of message should be defined, to avoid ambiguous use of these messages. Therefore, a new type of message named AtrgApdu is defined, which is detailed in section 4. This message is used by the Manager to trigger the Agent to request for association. To optimize the traffic flow, the AtrgApdu sent by the Manager should also contain the challenge, stored as the value of an AVA-Type attribute contained in the optionList field. The second message represents the Agent’s response to the triggered event received from the Manager. The AarqApdu message contains three important pieces of information: ‐ The Association Request triggered by the AtrgApdu message ‐ The response to the Manager’s challenge ‐ The challenge for the Manager The response to the Manager’s challenge is the output of an irreversible function that takes two inputs: the challenge and the cryptographic key. A new AVA-Type attribute is created having the id set to MDC_ATTR_AUTH_RESPONSE and value set to the computed response. This 12 Al. Egner, Florica Moldoveanu, Nicolae Goga, A. Moldoveanu, V. Asavei, Anca Morar attribute is stored in the optionList field contained in the AarqApdu message sent to the Manager. The challenge sent by the Agent ensures that the authentication procedure is mutual. The Agent’s challenge is generated identically to the one received from the Manager in the AtrgApdu message. This challenge is stored as the value of a new AVA-Type attribute that has the id set to MDC_ATTR_AUTH_CHALLENGE. This attribute is also added to optionList. The third message represents the Manager’s response to the Association Request. It also contains the authentication verdict and the response to the Agent’s challenge. If the authentication succeeds, the outcome stored in the field result of the AareApdu message is usually set to either accepted or accepted-unknownconfig, depending on the association information received from the Agent. If the authentication fails, the result is set to rejected-authentication-required and a new challenge is sent to the Agent. The response to the Agent’s challenge is determined identically to the one calculated by the Agent. A new AVA-Type attribute is created having the id set to MDC_ATTR_AUTH_RESPONSE and value set to the determined response. This attribute is stored in the optionList field of the AareApdu message. If the response of the AareApdu message is accepted, the Agent enters in the Operating state. In this state the association is considered established, the configuration of the device is known, authentication is ensured and medical data can be transmitted. 3.2. Bidirectional association when authentication is not required This section proposes the extension of the association procedure for systems that don’t employ any authentication mechanism. The mechanism is similar to the one used when authentication is required. Fig. 3.1 depicts the association message flow. In this case, the trigger message sent from the Manager to the Agent does not encapsulate any authentication information, such as the challenge. The field optionList of the AtrgApdu message is empty. The other two messages, i.e. AarqApdu and AareApdu, are identical to the ones used by the systems that implement the current specification of the protocol. The only extension of the protocol in this scenario is the AtrgApdu message, which represents just a trigger for the Agent to start the association phase. 4. The extended ASN.1 specification of OEP This section presents the ASN.1 definitions of the terms introduced to support the bidirectional association initiation. Enhanced communication protocol for ISO/IEEE 11073-20601 13 The first message depicted in Fig. 3.1, i.e. AtrgApdu, is not defined in the ISO/IEEE version of the standard. A new ASN.1 message definition should be added to the specification, as shown in Fig. 4.1. Fig. 4.1. Extended ASN.1 definition of ApduType with support for AtrgApdu The AtrgApdu message has a clearly defined purpose, i.e. to determine the Agent to start the association procedure. This message is not intended to be a container for medical data, or configuration information. The only piece of information stored in the AtrgApdu message is the authentication challenge, which is used when systems employ an authentication procedure. Therefore, the paper proposes that the AtrgApdu message type contains one optional field of type AttributeList, named optionList. AttributeList is a list of AVA-Type attributes, which are suitable containers for storing authentication information such as the challenge. AVA-Type attributes are adaptable to any changes regarding the challenge, such as its length, or type. If there is no authentication procedure employed, the optionList should be left empty. Fig. 4.2 shows the ASN.1 definition of the AtrgApdu message. Fig. 4.2. ASN.1 definition of AtrgApdu AVA-Type is a data type that specifies attribute objects characterized by attribute-ids and attribute-values. When instantiating new AVA-Type attributes, their attribute-ids must be set to values defined in the ISO/IEEE 11073-10101 – Nomenclature. Therefore, attributes used for storing authentication information should use two attribute-ids, i.e. MDC_ATTR_AUTH_CHALLENGE and MDC_ATTR_AUTH_RESPONSE. The definition of the two ids are added in the “Partition: ATTR/GROUP” section of the Nomenclature, as shown in Fig. 4.3. 14 Al. Egner, Florica Moldoveanu, Nicolae Goga, A. Moldoveanu, V. Asavei, Anca Morar Fig. 4.3. ASN.1 definition of challenge and response attribute-ids If no authentication is required, the AtrgApdu message contains an empty list of attributes. If authentication is required, the AtrgApdu contains a list that includes an AVA-Type attribute that has the attribute-id set to MDC_ATTR_AUTH_CHALLENGE and the attribute-value set to the value of the actual challenge. The extension of the protocol to allow the Manager to instantiate communication does not imply major changes in the standard. The behavior of the applications that implement the ISO/IEEE version of the protocol does not change and the new functionality can be easily implemented. 5. Illustration of association initiated by the Manager The section highlights the contents of the messages exchanged in the association process. For this illustration, a scenario where the mutual challengeresponse authentication is employed is considered. In this scenario, the challenge’s length is 64 bits, and the response is 128 bits. 5.1. The association trigger Fig. 5.1 describes the message sent by the Manager to initiate communication. This message corresponds to the first message depicted in Fig. 3.1. Fig. 5.1. Example of an AtrgApdu message Enhanced communication protocol for ISO/IEEE 11073-20601 15 5.2. The association request The Association Request contains the response to the Manager’s challenge and its own challenge. This message, which corresponds to the second message presented in Fig. 3.1, is detailed in Fig. 5.2. Fig. 5.2. Example of an AarqApdu message triggered by the AtrgApdu 5.3. The association response Since the authentication is mutual, the Manager must authenticate to the Agent, as well. The third message described in Fig. 3.1 represents the last step of the association process. This message contains the association outcome, the verdict to the Agent’s authentication attempt, and the response to the Agent’s challenge, if authentication succeeded. This message is constructed in a similar way to the messages presented in this section.